Skip to content

Conversation

@stephen-riggs
Copy link
Contributor

When we had the TUI we introduced logic for skipping processing in the case that someone started a fresh murfey with existing data. This no longer makes any sense as murfey can handle switching between tomo and SPA without a fresh instance.

Therefore this PR removes all skip_existing_processing and first_loop logic.

The case that needs checking is if processing is disabled, then it should not become enabled on reconnection. From the code this loops ok to me as the start_multigrid_watcher requests to the instrument server read session.process from the database.

@codecov
Copy link

codecov bot commented Jan 27, 2026

Codecov Report

❌ Patch coverage is 13.33333% with 13 lines in your changes missing coverage. Please review.
✅ Project coverage is 46.80%. Comparing base (0df33b0) to head (809e5a3).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #735      +/-   ##
==========================================
+ Coverage   46.59%   46.80%   +0.20%     
==========================================
  Files          91       91              
  Lines        9634     9664      +30     
  Branches     1262     1275      +13     
==========================================
+ Hits         4489     4523      +34     
+ Misses       4932     4928       -4     
  Partials      213      213              
🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

finalising: bool = False
dormant: bool = False
multigrid_watcher_active: bool = True
processing_enabled: bool = True
Copy link
Contributor

@tieneupin tieneupin Feb 2, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to confirm, by removing processing_enabled, are we moving towards relying entirely on the API calls from the backend server to determine whether the Analyser is activated for a given session?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The processing_enabled flag didn't really do what it says, the analyse one if the thing which determines whether the Analyser is activated

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got you. So, the MultigridController will have no attribute related to whether the Analyser should be triggered, but these will be directly set when setting up the RSyncers via the messages sent from the backend?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, the decision on whether to analyse happens in the call to _start_rsyncer_multigrid. The MultigridController knows whether it does have analysers, but you're right it doesn't know if it should have analysers or not

Copy link
Contributor

@tieneupin tieneupin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for addressing my comments. The changes look good to me, so feel free to merge once you're happy with it, and I can have a look at building and testing the recent changes we've made.

@stephen-riggs stephen-riggs merged commit 8739a6c into main Feb 3, 2026
17 checks passed
@stephen-riggs stephen-riggs deleted the no-force-metadata branch February 3, 2026 09:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants